jwezzyfandomcom-20200213-history
JSP:ACCESS
Web accessibility is the goal of making web pages easier to navigate and read. While this is primarily intended to assist those with disabilities, it can be helpful to all readers. We aim to adhere to Web Content Accessibility Guidelines 2.0 (also known as ISO/IEC 40500:2012) on which the following suggestions are based. Articles adhering to them are easier to read and edit for everyone. On 14 January 2006, the Board of the Wikimedia Foundation passed the following nondiscrimination resolution: . The WMF asserts that its policies Article structure A standardized structure of articles improves accessibility, because it enables users to expect contents to be in a specific part of the page. For example, a blind user is searching for disambiguation links. If he doesn't find any at the top of the page, he will know that there aren't any and he doesn't have to read the whole page to find that out. Standardization is already a habit on Wikipedia, thus the guidelines to follow are simply Wikipedia:Manual of Style/Layout and . Headings Headings should be descriptive and in a consistent order as defined in the Manual of Style. Nest headings sequentially, starting with level 2 ( ), then level 3 ( ) and so on. (Level 1 is the auto-generated page title.) Do not skip parts of the sequence, such as selecting levels for emphasis; this is not the purpose of headings. Do not make pseudo-headings by abusing semicolon markup (reserved for description lists) and try to avoid using bold markup. Screen readers and other assistive technology can only use headings that have heading markup for navigation. If you want to reduce the size of the table of contents (TOC), use instead. In cases where cannot be used because of lower-level headings elsewhere in the article, then using bold for the sub-sub-sub headings causes the least annoyance for screen reader users. Using a pseudo heading at all means you have exhausted all other options. It is a rarity. Floating elements In the wikicode, floating elements should be placed inside the section they belong to. For example, an image may be displayed under a header due to other floating elements pushing it down, while in the wikisyntax it is placed at the top of the page. Where this becomes problematic, some solutions exist at WP:Extended image syntax#The many-floating-objects problem. Images should be inserted inside the section they belong to. Resolution Wikipedia articles should be accessible to readers using devices with small screens, or to readers using monitors with a low resolution. The lowest resolution that it is considered possible to support without adversely affecting other users is 1024×768; all articles should look acceptable at this resolution without excessive horizontal scrolling. This is sometimes an issue in articles with multiple images on both sides of the screen; although lower resolutions will tend to stretch paragraphs vertically, moving images apart in that direction, be careful not to add images or other floating content on both sides of the screen simultaneously. Large tables and images can also create problems; sometimes horizontal scrolling is unavoidable, but consider restructuring wide tables to extend vertically rather than horizontally. Text In articles, do not use strikethrough to remove objectionable text. Either comment it out with "" or remove it entirely. By default, most screen readers do not indicate presentational text attributes (bold, italic, underline) or even semantic text attributes (emphasis, importance, text deletion), so struck-out text is read normally along with any other text. (Editors using screen readers who participate in Wikipedia policy and deletion debates are advised to turn on notifications about text attributes when doing so, as struck text is very common in Wikipedia-internal discussions.) Screen readers without Unicode support will generally read a character outside Latin-1 and Windows-1252 as a question mark, and even in JAWS, the most popular screen reader, Unicode characters are very difficult to read. # Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc. # Do not use unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead. # Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template (see Category:Single-image insertion templates for more). Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text. Abbreviations are exempt from these requirements, so the template may be used to indicate the long form of a word. Do not insert line breaks within a sentence, since this makes it harder to edit with a screen reader. A single line break may follow a sentence, which may help some editors. Font size Reduced or enlarged font sizes should be used sparingly, and are usually done with automated page elements such as headings, table headers, and standardized templates. Size changes are specified as a of the original font size and not as an absolute size in pixels or point size. This improves accessibility for visually impaired users who use a large default font size. Avoid using smaller font sizes in elements that already use a smaller font size, such as infoboxes, navboxes, and reference sections. In no case should the resulting font size drop below 85% of the page's default font size (i.e. 11.9 px in Vector skin or 10.8 px in Monobook). Other languages Non-English words or phrases should be encased in , which uses ISO 639 language codes, thus: which renders as or which renders as . : enables speech synthesizers to pronounce the text in the correct language.H58: Using language attributes to identify changes in the human language, Techniques for WCAG 2.0, W3C, accessibility level: AA. It has many other uses; see for a comprehensive list of benefits. 2018 update: It is no longer necessary or desirable to wrap these constructions in italics markup; the and templates already auto-italicize. Links # Create good link descriptions, especially for external links (avoid "click here!", "this"). # Do not use Unicode characters as icons; use an icon with alt text instead. For example, a character like "→" can not be reproduced into useful text by a screen reader, and will usually be read as a question mark. Color Colors are most commonly found in Wikipedia articles within templates and tables. For technical assistance on how colors are used, see . Articles (and other pages) that use color should keep accessibility in mind, as follows: * Ensure that color is not the only method used to convey important information. Especially, do not use colored text or background unless its status is also indicated using another method such as an accessible symbol matched to a legend, or footnote labels. Otherwise, blind users or readers accessing Wikipedia through a printout or device without a color screen will not receive that information. * Links should clearly be identifiable as a link to our readers. * Some readers of Wikipedia are partially or fully color-blind. Ensure the contrast of the text with its background reaches at least Web Content Accessibility Guidelines (WCAG) 2.0's AA level, and AAA level when feasible (see WCAG's "Understanding SC 1.4.3: Contrast (Minimum)"). To use named CSS colors for text on a white background, refer to Wikipedia:Manual of Style/Accessibility/CSS colors for text on white for recommended colors. For other usage, here is a selection of tools that can be used to check that the contrast is correct: ** The Colour Contrast Analyser enables you to pick colors on the page, and review their contrast thoroughly. However, be sure to only use the up-to-date "luminosity" algorithm, and not the "color brightness/difference" which is outdated. ** You can also use Snook's color contrast tool, which is entirely up-to-date . ** Google's Chrome Canary has a color contrast debugger with visual guide and color-picker ** Several other tools exist on the web, but check if they are up-to-date before using them. Several tools are based on WCAG 1.0's algorithm, while the reference is now WCAG 2.0's algorithm. If the tool doesn't specifically mention that it is based on WCAG 2.0, assume that it is outdated. * Additional tools can be used to help produce graphical charts and color schemes for maps and the like. These tools are not accurate means to review contrast accessibility, but they can be helpful for specific tasks. ** The color scheme generator helps to choose a good set of colors for a graphical chart. ** Color Brewer 2.0 provides safe color schemes for maps and detailed explanations. ** There are some tools for simulating color-blind vision: toptal (webpage analysis) and coblis (local file analysis). There are also browser extensions for webpage analysis: Colorblinding (Chrome) NoCoffee (Chrome) NoCoffee (Firefox) * If an article overuses colors, and you don't know how to fix it yourself, you can ask for help from other editors. Place ( or ) at the top of the article. Block elements Lists Do not separate list items by leaving empty lines or tabular column breaks between them. This includes items in a description list (a list made with a leading semicolon or colon) or an unordered list. Lists are meant to group elements that belong together, but MediaWiki will interpret the blank line as the end of one list and start a new one. Excessive double line breaks also disrupt screen readers, which will announce multiple lists when only one was intended, and therefore may mislead or confuse users of these programs. Such improper formatting can also more than triple the length of time it takes them to read the list. Likewise, do not switch between initial list marker types (colons, asterisks or hash signs) in one list. For example, in a discussion, do this best practice: * Support. I like this idea. User:Example ** Question: What do you like about it? User:Example 2 or this acceptable practice: * Support. I like this idea. User:Example *: Question: What do you like about it? User:Example 2 but don't do this (switch type from bullet list to description list): * Support. I like this idea. User:Example :: Question: What do you like about it? User:Example 2 nor this (switch type from bullet list to description list): * Support. I like this idea. User:Example :* Question: What do you like about it? User:Example 2 nor this (leave blank lines between list items): * Support. I like this idea. User:Example ** Question: What do you like about it? User:Example 2 nor this (jump more than one level): * Support. I like this idea. User:Example *** Question: What do you like about it? User:Example 2 Multiple paragraphs within list items Normal MediaWiki list markup is unfortunately incompatible with normal MediaWiki paragraph markup. To put multiple paragraphs in a list item, separate them with : * This is one item. This is another paragraph within this item. * This is another item. Do not use line breaks to simulate paragraphs, because they have different semantics: * This is one item. This is the same paragraph, with a line break before it. * This is another item. Definitely do not attempt to use a colon to match the indentation level, since (as mentioned above) it produces three separate lists: * This is one item. : This is an entirely separate list. * This is a third list. Indentation An accessible approach to indentation is the template for multi-line content; it uses CSS to indent the material. For single lines, a variety of templates exist, including (a universal template, with the same name on all Wikimedia sites); these indent with various whitespace characters. Do not abuse the element or templates that use it (such as ) for visual indentation; they are only for directly quoted material. A colon (:) at the start of a line marks that line in the MediaWiki parser as the part of an HTML description list ( ). The visual effect in most Web browsers is to indent the line. This is used, for example, to indicate replies in a threaded discussion on talk pages. However, this markup alone is missing the required (term) element of a description list, to which the (description/definition) pertains. As can be seen by inspecting the code sent to the browser, this results in broken HTML (i.e. it fails validation The validator failure reported is "Error: Element dl is missing a required child element."). The result is that assistive technology, such as screen readers, will announce a description list that does not exist, which is confusing for any visitor unused to Wikipedia's broken markup. This is not ideal for accessibility, semantics, or reuse, but is currently commonly used, despite the problems it causes for users of screen readers. Blank lines must be placed between colon-indented lines of text – especially in article content. This is interpreted by the software as marking the end of a list and the start of a new one. If a blank line is needed, place the same number of colons on it as those preceding the text below the blank line, for instance: : Text here. : : More text. Another solution is new-paragraph markup, but it must be in one unbroken line in the wiki code: : Text here. More text. For more information on the weaknesses of colon-based description list markup – even for actual description lists – . Vertical lists Bulleted vertical lists For bulleted vertical lists, do not separate items by leaving blank lines between them. If list items are separated by more than one line break, the HTML list will be ended before the line break, and another HTML list will be opened after the line break. This effectively breaks what is seen as one list into several smaller lists for those using screen readers. For example, for the coding: * White rose * Yellow rose * Pink rose * Red rose the software partially suppresses line spaces and therefore it looks like this: * White rose * Yellow rose * Pink rose * Red rose but will be read by a screen reader as: "List of 2 items: (bullet) White rose, (bullet) Yellow rose, list end. List of 1 items: (bullet) Pink rose, list end. List of 1 items: (bullet) Red rose, list end." Do not separate list items with line breaks ( ). Use / if the list is to remain vertical; or consider / if the list could be better rendered horizontally (inline) as described in the following two sections. Unbulleted vertical lists For unbulleted lists running down the page, the templates and are available, to improve accessibility and semantic meaningfulness by marking up what is clearly a list rather than including line breaks, which should not be used—see above. They differ only in the wiki-markup used to create the list. Note that because these are templates, the text of each list item cannot contain the vertical bar symbol (|) unless it is replaced by or is contained within tags. Similarly it can't contain the equals sign (=), unless replaced with or contained within , though you can bypass this by naming the parameters (|1=, |2= etc.). If this becomes too much of a hassle, you may be able to use the variant using instead. Alternatively, in templates such as Navboxes and the like, or any suitable container, such lists may be styled with the class "plainlist", thus: In infoboxes: may be used. See also Manual of Style: Lists § Unbulleted lists. See WP:NAV for more details on Navigation templates. Horizontal lists For lists running across the page, and in single rows in infoboxes and other tables, the templates and ("horizontallist") are available to improve accessibility and semantic meaningfulness. This feature makes use of the correct HTML markup for each list item, rather than including bullet characters which, for example, are read out (e.g., "dot cat dot dog dot horse dot...") by the assistive software used by people who are blind. The templates differ only in the wiki-markup used to create the list. Note that because these are templates, the text of each list item cannot contain the vertical bar symbol ( | ) unless it is replaced by or is contained within tags. Alternatively, in templates such as Navboxes and the like, or any suitable container, such lists may be styled with the class hlist, thus: In infoboxes: may be used. List headings Improper use of a semicolon to bold a "fake heading" before a list (figure 1) creates a list gap, and worse. The semicolon line is a one-item description list, with no description content, followed by a second list. Instead, use heading markup (figure 2). 1. Incorrect ; Noble gases * Helium * Neon * Argon * Krypton * Xenon * Radon 2. Heading Noble gases * Helium * Neon * Argon * Krypton * Xenon * Radon Tables Screen readers and other web browsing tools make use of specific table tags to help users navigate the data contained within them. Use the correct wikitable pipe syntax to take advantage of all the features available. See meta:Help:Tables for more information on the special syntax used for tables. Do not solely use formatting, either from CSS or hard-coded styles, to create semantic meaning (e.g., changing background color). Many navboxes, series templates, and are made using tables. Avoid using tags in adjacent cells to emulate a visual row that isn't reflected in the HTML table structure. This is a problem for users of screen readers which read tables cell by cell, HTML row by HTML row, not visual row by visual row. Project Accessibility/Infobox accessibility has been addressing this problem. Data tables ; Caption ( |+ ): A caption is a table's title, describing its nature.H39: Using caption elements to associate data table captions with data tables, A accessibility level. ; Row & column headers ( ! ): Like the caption, these help present the information in a logical structure to visitors. The headers help screen readers render header information about data cells. For example, header information is spoken prior to the cell data, or header information is provided on request. ; Scope of headers ( ! scope="col" | and ! scope="row" | ): This clearly identifies headers as either row headers or column headers. Headers can now be associated to corresponding cells. Wikipedia:Manual of Style/Accessibility/Data tables tutorial provides detailed requirements about: # Correct table captions # Correct headers structure # Images and color # Avoiding nested tables Layout tables Avoid using tables for visual positioning of non-tabular content. Data tables provide extra information and navigation methods that can be confusing when the content lacks logical row and column relationships. Instead, use semantically appropriate elements or s, and style attributes. When using a table to position non-tabular content, help screen readers identify it as a layout table, not a data table. Set a role="presentation" attribute on the table, and do not set any summary attribute. Do not use any or elements inside the table, or inside any nested tables. In wiki table markup, this means do not use the |+ or ! prefixes. Make sure the content's reading order is correct. Visual effects, such as centering or bold typeface, can be achieved with style sheets or semantic elements. For example: Images # Images that are not purely decorative should include an alt attribute that acts as a substitute for the image for blind readers, search-spiders, and other non-visual users. If additional alt text is added it should be succinct, or should refer the reader to the caption or adjacent text: see WP:ALT for more information. # In most cases, images should contain a caption using the built in image syntax. The caption should concisely describe the meaning of the image, the essential information it is trying to convey. # Where possible, any charts or diagrams should have a text equivalent, or should be well-described so that users who are unable to see the image can gain some understanding of the concept. # Detailed image descriptions, where not appropriate for an article, should be placed on the image description page, with a note saying that activating the image link will lead to a more detailed description. # Images should be inside the section they belong to (after the heading and after any links to other articles), and not in the heading nor at the end of the previous section, otherwise screen readers would read the image (and its textual alternative) in a different section; as they would appear to viewers of the mobile site. See Wikipedia:Picture tutorial for more information. # Avoid referring to images as being on the left or right. Image placement is different for viewers of the mobile version of Wikipedia, and is meaningless to people having pages read to them by assistive software. Instead, use captions to identify images. # This guideline includes alt text for LaTeX-formatted equations in mode. # Do not put images in headings; this includes icons and markup. Doing so can break links to sections and cause other problems. Animations, video, and audio content Animations To be accessible, an animation (GIF – Graphics Interchange Format) should either: * Not exceed a duration of five seconds (which results in making it a purely decorative element) or * Be equipped with control functions (stop, pause, play) This requires GIFs with animations longer than five seconds to be converted to video (to learn how, see the tutorial converting animated GIFs to Theora OGG). In addition, animations must not produce more than three flashes in any one-second period. Content that flashes more than that limit is known to cause seizures. Video Subtitles can be added to video, in timed text format. There is a corresponding help page at commons:Commons:Video#Subtitles and closed captioning. Subtitles are meant for the transcription of speech. There is a need for closed captions for the hearing impaired. As of November 2012 this is not possible, but this feature could be easily added and has been requested in bugzilla:41694. Closed captions are meant to be viewed instead of subtitles. Closed captions provide a text version of all important information provided through the sound. It can include dialogue, sounds (natural and artificial), the setting and background, the actions and expressions of people and animals, text or graphics. Off-Wikipedia guides should be consulted for how to create closed captions.Please see : A quick and basic reference for closed captions, a detailed reference (PDF) and a list of best practices for closed captions. A text version of the video would also be needed for the blind, but as of November 2012 there is no convenient way to provide alt text for videos. Audio Subtitles for speech, lyrics, dialogue, etc. can easily be added to audio files. The method is similar to that of the video: commons:Commons:Video#Subtitles and closed captioning. Styles and markup options Best practice: Use Wikimarkup and CSS classes in preference to alternatives In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes. The site-wide CSS in MediaWiki:Common.css is more carefully tested to ensure accessibility (e.g. sufficient color contrast) and compatibility with a wide range of browsers. Moreover, it allows users with very specific needs to change the color schemes in their own style sheet ( , or their browser's style sheet). For example, a style sheet at Wikipedia:Style sheets for visually impaired users provides higher contrast backgrounds for navboxes. The problem is that when the default site-wide classes are overridden, it makes it far more difficult for an individual to choose his/her own theme. It also creates a greater degree of professionalism by ensuring a consistent appearance between articles and conformance to a style guide. Regarding accessibility, deviations from standard conventions may be tolerated so long as they are accessible. Members of the accessibility project have ensured that the default style is accessible. If some template or specific color scheme deviates from the standard, its authors should make sure that it meets accessibility requirements such as providing enough color contrast. For instance, the infoboxes and navigational templates relating to The Simpsons use a yellow color scheme, to tie in with the dominant color in the series. In this case, blue links on yellow provide enough color contrast, and thus are accessible. In general, articles should use wikimarkup in preference to the limited set of allowed HTML elements. In particular, do not use the HTML style elements and to format text; it is preferable to use Wiki-markup '' or ''' for purely typographic italicisation and boldfacing, respectively, and use semantic markup templates or elements for more meaningful differences. The element should also be avoided in article text; use , , , and our other semantic markup templates as needed, to emphasise logical differences not just visual ones. Use the , , and templates to change font size, rather than setting it explicitly with CSS style attributes like font-size or deprecated style elements like . Of course there are natural exceptions; e.g., it may be beneficial to use the element to indicate something like an example link that isn't really clickable, but underlining is otherwise generally not used in article text. Users with limited CSS or JavaScript support Auto-collapsed (pre-collapsed) elements should not be used to hide content in the article's main body, though elements such as tables can be made collaps at the reader's option. Wikipedia articles should be accessible to readers using browsers and devices that have limited or no support for JavaScript or Cascading Style Sheets; remember that Wikipedia content can be reused freely in ways we cannot predict as well as accessed directly via older browsers. At the same time, it is recognised that it is impossible to provide the same quality of appearance to such users without unnecessarily avoiding features that would benefit users with more capable browsers. As such, features that would cause content to be hidden or corrupted when CSS or JavaScript is unavailable must not be used. This includes techniques such as the deprecated hiddenStructure method for hiding table content (which produces incomprehensible output without CSS) and some implementations of the NavFrame collapsing code (which can make content inaccessible without JavaScript support). However, consideration for users without CSS or JavaScript should extend mainly to making sure that their reading experience is ; it is recognised that it will inevitably be . To accommodate these considerations, test any potentially disruptive changes with JavaScript or CSS disabled. In Firefox or Chrome, this can be done easily with the Web Developer extension; JavaScript can be disabled in other browsers in the "Options" screen. Be particularly careful with inline CSS effects, which are not supported by several browsers, media, and XHTML versions. See also * Wikipedia:Accessibility dos and don'ts (information page summarizing the key points of this guideline) * Usability:Accessibility Initiative * Web Accessibility Initiative (WAI) * Wikipedia:Accessibility advocates * Wikipedia:Dyslexic readers * Wikipedia:Make technical articles understandable * Wikipedia:Using JAWS * Wikipedia:WikiProject Accessibility * Wikipedia:WikiProject Usability Notes and references Specific General * * Technical External links * 10 Quick Tips to Make Accessible Web Sites, from WAI * Colorblind web page filter * Essential Components of Web Accessibility, from WAI * Introduction to Web Accessibility, from WAI * MediaWiki bug 367: Markup accessibility issues (tracking) Category:Wikipedia accessibility Category:Wikipedia Manual of Style (content) Manual of Style (accessibility)